RoR_chapter4 現実の複雑さに対応する

RoR_chapter4 現実の複雑さに対応する

マイグレーション

DBにインデックスを貼ったり修正したりする操作をもう少し深掘りする

以下の2ステップが基本。Laravelと同じ

DBスキーマを変更するmigrationファイルを作成

Railsは基本的に3つの環境があるので、開発用、テスト用、本番用のものを使い分ける。

またロールバックも同様に可能

railsがテーブルを作る処理のものを逆側に汲み取って、削除するような処理と判断してくれる

laravelのようにプログラマが削除する処理を書くこともできる

schema.rb

DBの構造が保管されているテーブルで、マイグレーションを適用すると自動で出力される

マイグレーションでエラー発生時はlaravelのように途中で止まるのではなく、ロールバックしてくれる

データ内容の制限

taskleafのnameカラムに not null制約をつけよう

code:txt

bin/rails g migration ChangeTasksNameNotNull

作った後は、bin/rails db:migrateで反映させる。

カラムの詳細を変えるタイミング

今からtasksテーブルを作る段階ならば、テーブル作成時のmigrationを修正する

もう既に運用済みの場合ならば、変更専用のmigrationを作って対応するのが良い。

コマンドが動かない時

マイグレーション適用テスト

code:txt

bin/rails s

irb(main):002:0> Task.new(name: nil).save

# 例外発生（not null制約）。

ActiveRecord::NotNullViolation (PG::NotNullViolation: ERROR: null value in column "name" of relation "tasks" violates not-null constraint)

# コンソールでこんな感じで作れる

Task.new(name: "consoleで。").save

文字列カラムの長さ指定などもできるので、必要になったら調べる。

ユニークインデックス

あるテーブルのカラムのデータが全レコードで一意だった時に使う

ユニークインデックスを作成することで一意性が壊されるのを防ぐことができる

重複した値がデータベースに存在することがなくなるため、便利

モデルの検証機能について

マイグレーションでのデータ値の規制だけでは、webで入力する値のエラー全てをカバーしきれない

not null制約や文字列が長すぎる場合の指定など、ユーザーにとっては不具合で止まったとしかわからない。

バリデーションとDBの制限を行なっておくことがかなり確実

検証の流れ

モデルをDB登録する前に検証を行い、エラーが起こった場合差し戻すという流れ

saveメソッドは自動で検証を行い、エラーならfalseを返す。

またこの時、errorsを通じてエラー詳細にアクセスすることができる

検証は、検証処理単独でも呼ぶことができる。

検証エラー時に、falseを返すのではなく例外を発生させるという仕組み

例外が出なければDBへの登録が行われる流れ。予期しない失敗を防ぐことができる

検証をスルーする

検証を書く

1. Railsが用意している検証用のヘルパを使う

2. 自分で任意の検証コードを書く

1. Railsが用意している検証用のヘルパを使う

code:task.rb

class Task < ApplicationRecord

validates :name, presence: true

end

code:rb

irb(main):003:0> task = Task.new

irb(main):004:0> task.save

(0.2ms) BEGIN

(0.2ms) ROLLBACK

=> false

# errorsでエラー確認

irb(main):008:0> task.errors

irb(main):010:0> task.errors.full_messages

オブジェクトがDBに登録済みかどうかチェックする関数もある。

task.persisted?

入れた場合は成立するかもチェック。

code:rb

irb(main):014:0> task.name = "テストタスク"

irb(main):016:0> task.save

=> true

irb(main):018:0> task.persisted?

=> true

コントローラとビューで検証エラーへの対応をする

ユーザーにエラーの詳細を伝えるということ

上のバリデーションを貼って画面で更新すると、今こんな感じ

https://scrapbox.io/files/63ea30bd09eb47001b720f05.png

createメソッドを変更しよう

code:rb

def create

@task = Task.new(task_params)

if @task.save

redirect_to @rask, notice: "タスク「#{@task.name}」を登録しました。"

else

render :new

end

end

変えたところ

成功したか失敗したかの戻り値によって処理を変更するように変更

render :new

falseだった時、登録用のビューを呼んで再入力を促す。

エラーで新規登録画面に戻す時、Taskオブジェクトを渡すため。

フォームへ送信したデータを引き継がせて入れたり、エラーの情報をビューに渡せる

フォームにエラーのメッセージを表示する項目を作る

code:slim

# errors.present? で、エラーの有無を調べて、あった場合は指定のhtmlタグを作る

- if task.errors.present?

ul#error_explanation

- task.errors.full_messages.each do |message|

li= message

2. 自分で任意の検証コードを書く

検証を行うメソッドを追加し、そのメソッドを検証用メソッドとして指定する方法

特定のモデル専用の処理を作りたいならこっち

自前のvalidatorを作って利用する方法

汎用的なものを書くときはこちら

検証用メソッドをモデルクラスに登録し、実装する

code:task.rb

class Task < ApplicationRecord

validates :name, presence: true

validates :name, length: { maximum: 30 }

validate :validate_name_not_including_comma # methodを記述する

private

def validate_name_not_including_comma

errors.add(:name, 'にカンマを含めることはできません') if name&.include?(',')

end

end

nameがnilの時は検証が通るようにしている(nameなんてものはありません、というエラーが出なくなる）

検証が行われない登録・更新の動作

コールバック

code:task.rb

class Task < ApplicationRecord

# 検証のサイクルの前に、set_nameless_nameメソッドを実行する

before_validation :set_nameless_name

...

private

def set_nameless_name

self.name = '名前なし' if name.blank?

end

ログイン機能の実装

セッションとcookie

違いについて

cookieはブラウザにだけ保存され、セッションはサーバ側にも情報が保存される

cookieはサイトを閉じても保存されるが、セッションはユーザーがサイトから離脱すると消える。

セッション

cookie

railsではセッションの仕組みがcookieによって実現されている

cookieによってやりとりされるセッションをキーにして保管される

Userモデルの作成

code:rb

# bin/rails 作成(generate) 作成するもの 名前(単数) カラム1:タイプ カラム2:タイプ...

bin/rails g model user name:string email:string password_digest:string

Running via Spring preloader in process 85867

invoke active_record

create db/migrate/20230802125802_create_users.rb

create app/models/user.rb

invoke test_unit

create test/models/user_test.rb

create test/fixtures/users.yml

migrationファイルが作られるので、少し調整して反映する

bin/rails db:migrate

パスワードを暗号化して保管する

ロールを分ける

Userモデルにadminフラグを追加して管理する

bin/rails g migration add_admin_to_users

code:add_admin_to_users.rb

def change

add_column :users, :admin, :boolean: default: false, null:false

end

end

ユーザー管理のためのコントローラを実装する

bin/rails g controller Admin::Users new edit show index

railsではモジュール空間と、コード保存のためのディレクトリ構造とが対応している

今回は管理者が「ユーザー」を管理するコントローラということでこういう作りにした

ページを作っていく

human_attribute_xxx

td= link_to user.name, [:admin, user]

user.nameの名前を画面に出して

詳細画面(show)

td= @user.admin? ? 'あり': 'なし'

条件式 ? 真の時の値 : 偽の時の値

例外的な条件で例外的な値を返すのであれば、処理の冒頭部分で条件判断とreturnを行って例外処理を完結させる

4-5-5 ログイン機能の実装

ログインするためのフォーム画面

画面から送られてきた情報を元にユーザーを認証する

ログアウト機能

table:ログイン

アクション内容 HTTPメソッド URL アクション名

ログインフォームを表示 GET /login new

フォーム情報を元に認証 POST /login create

ログアウト DELETE /logout destroy

フォーム画面を作る

セッションを作るための処理を書くコントローラを作る

bin/rails g controller Sessions new

URLを変える

ログインの実行

POSTメソッドのcreateアクションを作成する

code:route.rb

get '/login', to: 'sessions#new'

post '/login', to: 'sessions#create' # 追加

処理を書く

code:session_controller.rb

def create

# ユーザーをemailで取得

# パスワードの認証をauthenticateメソッドで行う

redirect_to root_url, notice: 'ログインしました。'

else

render :new

end

end

private

# パラメータがsession{...}の形なのかをチェックし、その中から:email,:passwordのパラメータを抜き取る

# CSRF対策, 適当なパラメータが送られた場合、その情報で更新されてしまうのを防ぐ.

def session_params

params.require(:session).permit(:email, :password)

end

if user&.authenticate(session_params[:password])

authenticate

引数で受け取ったpasswordをハッシュ化する

その結果がUserオブジェクト内部に保存されているdigestと一致するかを調べる

暗号の分野では、暗号化（ダイジェスト）された文字列をメッセージダイジェストと呼びます。メッセージダイジェストは、元の文字列に戻すことができません。

一致していたらuserオブジェクト自身を返し、不一致であればfalseを返す

&.

ぼっち演算子

if後の処理について

つまりこの処理で、以下の形になった

ログイン情報の取得を簡単にする

ユーザーが既にログインしている場合、その情報を取得する

User.find_by(id: session[:user_id])

こういった処理はいろんな画面で使う（会員用ページなら全部書く必要があったりする）

そのため全てのコントローラから利用できるようにする

code:application_controller.rb

class ApplicationController < ActionController::Base

helper_method :current_user

private

def current_user

end

end

全てのビューから呼ぶことができるようにする

current_user

||=

nilガード

ログアウトの実装

ルーティング記述

delete '/logout', to: 'sessions#destroy'

アクション記述

code:rb

def destroy

# session.delete(:user_id) でも良い

reset_session

redirect_to root_url, notice: 'ログアウトしました'

end

ビュー記述

code:rb

ul.navbar-nav.ml-auto

- if current_user

li.nav-item= link_to 'タスク一覧', tasks_path, class: 'nav-link'

li.nav-item= link_to 'ユーザー一覧', admin_users_path, class: 'nav-link'

li.nav-item= link_to 'ログアウト', logout_path, method: :delete, class: 'nav-link'

- else

li.nav-item= link_to 'ログイン', login_path, class: 'nav-link'

セッションはサーバが持つ情報

ユーザーが離脱すると消える

明日もう一度見る

ログインした状態で時間を置くので消えているのかチェック

ログイン振り返り

code:html.slim

.container

こう書くとログインしているユーザーのIDを画面に出せる

ユーザーがログインしていればsessionに値があるので、その値でfindするというだけ

ログインしていなければ各ページへアクセスできないようにする

コントローラのフィルタ機能を使う

アクションを処理する前後に任意の処理を挟む事ができる。

今回の仕様

ユーザーがログインしているかどうかを調べる

ログインしていれば遷移させ、していなければログイン画面にリダイレクトさせる。

タスクページだけに制限をかけたいのであればtasks_controller.rbに書けば良い

ただ今回はログイン判断という全ページで使う処理なので、application_controllerに記述する。

code:application_controller.rb

before_action :login_required

def login_required

redirect_to login_url unless current_user

end

current_userヘルパを呼び出し、current_userに何も値が入っていないならログイン前と判断

ログイン画面の場合でもこの処理が行われてしまうので、ログイン関連の画面だけ許可する

code:rb

# スキップしたいコントローラに以下を記述する

skip_before_action :login_required

ログインユーザーのデータだけを扱えるようにする

taskleafにログインして見えるタスクは、そのユーザーが登録したタスクだけにしたい。そのために

UserとTaskを紐づける

tasks.user_idの追加

リレーションの定義

ログインしているユーザーに紐づくtaskデータを登録できるようにする

一覧・詳細・変更画面はログインユーザーに紐づくデータだけを扱う

UserとTaskの紐づけ

bin/rails g migration AddUserIdToTasks

code:migrate/20230907150009_add_user_id_to_tasks.rb

def up

execute 'DELETE FROM tasks;'

add_reference :tasks, :user, null: false, index: true

end

def down

remove_reference :tasks, :user, index: true

end

end

既存のタスクを全部一旦消してから

add_reference(テーブル名, リファレンス名, オプション)

↑が複数形と単数系なのは、userに対してtasksは1対多だからっぽい

マイグレーションの実行

code:txt

rails db:migrate

DB上の紐付けを前提にして、Modelも紐付けの定義をする事ができる

今回はユーザーに対して、タスクが複数

code:rb

# task.rb

belongs_to :user

# user.rb

has_many :tasks

これで２通りのメソッドが使える

タスク登録時の挙動を修正する

code:rb

# 今

@task = Task.new(task_params)

# 修正(2通り書ける)

@task = Task.new(task_params.merge(user_id: current_user.id)

@task = current_user.tasks.new(task_params) # 関連を宣言したので呼べる

param系統で使える

通常、railsはストロングパラメータという仕組みを採用している

Web上から受けつけたパラメータが、本当に安全なデータかどうかを検証した上で、取得するための仕組みです。Rails4から実装されています。

params.require(:task).permit(:name, :description)

基本上のように、フォームから渡された値をpermitで許可し、その値を通す

mergeメソッドを使うことでパラメータで受け取った値ではないが追加したい値を格納することができる

@tasks = Task.all

これだとDBの全部のタスクを取得する動きになるので指定する

code:rb

@tasks = current_user.tasks # 関連で呼べるようになった

@tasks = Task.where(user_id: current_user.id)

どっちでも良い

カラムの真偽値を取得する

ユーザー登録画面を管理者用の画面とする

code:rb

class Admin::UsersController < ApplicationController

before_action :require_admin

...

private

...

def require_admin

redirect_to root_url unless current_user.admin?

end

end

ただしリダイレクトするということは存在を知られることでもあるので、ステータスコード404を返すようにしても良い。

初期データの考え方

ユーザー作成画面を管理者専用にした場合、最初の管理者はどうやって作るか

通常通り、コンソールでコードを実行して作れば良い。

RailsのDB取得動作

起点 . 絞り込み条件 . 実行部分

起点

モデルを記述するのが基本。

assosicationを付けておけば、関連するモデルも起点として使用できる。

current_user.tasks

絞り込み条件

join

SQLのjoinを作成する。

none

何もヒットしない検索条件

DBに検索には行かないが、何もヒットしなかったということを明確にして処理を書く時に使う

実行部分

その他

データ取得処理に繋げることで生成予定のSQLを見ることができるので便利。

code:rb

logger.debug "【LOG】#{current_user.tasks.to_sql}}"

# 【LOG】SELECT "tasks".* FROM "tasks" WHERE "tasks"."user_id" = 4}

scopeの活用

絞り込みの条件を名づけてメソッドとして保管できる。

code:task.rb

class Task < ApplicationRecord

...

belongs_to :user

scope :recent, -> { order(created_at: :desc)}

private

...

end

code:rb

# @tasks = current_user.tasks.order(created_at: :desc) と同じ意味

@tasks = current_user.tasks.recent

taskコントローラにもフィルタを使う

@task = current_user.tasks.find(params[:id])

変更するときに4箇所の修正が必要となり大変なので、フィルタ機能を使って処理をまとめる

フィルタについておさらい

上のリンクでは、アクションの処理を行う前にログインしているかどうかを挟んでいた

4-10 URLをリンクとして判断させる